In a client/server computing environment in which clients communicate with servers over non-secure networks, enabling only authorized clients to receive services from the servers presents a variety of technical problems. In one approach, identifying information is collected from each client, and only known clients are given services from a server. In one implementation of this approach, a host that originates a request for services must provide its source IP address to the receiving server.
However, in this approach, there is a need to minimize the number of times that the client identifying information travels across the network, in order to prevent interception and spoofing. For example, allowing the IP address to be passed explicitly as part of a secure protocol message could represent a security weakness; a client could intentionally supply an incorrect address to gain greater access. Unfortunately, not allowing the address to be passed explicitly at all means that important identifying information is not available to the receiving server.
FIG. 1A is a simplified block diagram of a client/server system in which this general problem may arise. One or more clients 1112A, 1112B are coupled to a network 1104. Each client 1112A, 1112B is a network end station device such as a personal computer, workstation, or the equivalent. Alternatively, each client 1112A, 1112B is a process, such as a standard Web browser. The term “originating host” is used herein to refer to any of clients 1112A, 1112B. Although only two clients are shown in FIG. 1A, in a practical system there may be any number of such clients.
Network 1104 is one or more local area networks, wide area networks, or internetworks, alone or in combination. In a preferred embodiment, network 1104 is the global, packet-switched internetwork known as the Internet.
An HTTP server 1130 is coupled to network 1104 in a position logically separate from clients 1112A, 1112B. HTTP server 1130 comprises one or more servers or software elements that can respond to client requests received in the Hypertext Transfer Protocol (HTTP). HTTP server 1130 may have one or more associated application servers that provide other services.
HTTP server 1130 stores or manages session data 1140, which comprises a plurality of records that identify clients that are authorized to receive services from the HTTP server. In an embodiment, session data 1140 is created and stored by HTTP server 1130 for the purpose of uniquely identifying clients that are authorized to access HTTP server 1130, its resources, or other associated servers and resources. Each record in session data 1140 includes a key 1141 that includes, among other data, client IP address values 1144A, 1144B associated or paired with random number values 1142A, 1142B. For purposes of illustrating an example, two (2) keys 1141 are shown in FIG. 1A, however, in a practical system there may be any number of keys or other information in session data 1140.
Each IP address value 1144A, 1144B normally represents an Internet Protocol (IP) address that is pre-assigned to and uniquely associated with one of the clients 1112A, 1112B. In conventional usage, IP addresses are uniquely associated with specific client hardware such as a particular workstation or personal computer. However, such a hardware device may execute a plurality of instances of client applications, such as Web browsers. Accordingly, random values 1142A, 1142B may be used in order to uniquely identify more than one instance of a browser that is running on the same physical machine. Random values 1142A, 1142B are generated by HTTP server 1130 when a client having an authorized IP address connects to the HTTP server.
FIG. 1B is a simplified block diagram of a system similar to that of FIG. 1A, in which like numbered blocks represent like elements. In FIG. 1B, however, a proxy server 1108 is coupled to network 1104 for the purpose of providing services that complement, but are not available in, an application server 1106, which is also coupled to network 1104.
Proxy servers are useful for merging functionality from different servers. For example, assume that application server 1106 offers Secure Sockets Layer functions, but not servlet capabilities, and proxy server 1108 can provide servlet functions. In this case, proxy server 1108 can act as proxy for application server 1106. Proxy server 1108 receives such requests from clients 1112A, 1112B and can respond to them. However, to carry out a response, proxy server 1108 may need a service or information from application server 1106, by communication over logical path 1110. When application server 1106 receives a service request from proxy server 1108, the application server stores the IP address of the proxy server as part of a key of a record in session data 1140.
In a security scheme that requires the source IP address of the originating host, a system that includes a proxy server can result in problems. In particular, security can be compromised because the receiving server (e.g., application server 1106) always receives the IP address of the proxy server 1108 with a service request, rather than the IP address of the clients 1112A, 1112B that originate service requests.
One responsive measure is not allowing the address to be passed explicitly at all in the protocol, however, in that case important identifying information is not available to the receiving server. If the address is passed, security is reduced because all accesses appear to originate from the proxy server.
Based on the foregoing, there is a need in this field for a way to pass originating client or host network address information through a proxy server to a receiving server, in a secure manner.
There is a specific need for a way to pass the IP address of a Web client through a proxy server to an HTTP server or application server, in a secure protocol that does not always allow the IP address to be passed.
In the client/server computing environment a need may arise to enable a client to communicate with two servers, each of which provide functions that represent a portion of a service desired by the client. In some cases, it is desirable to permit the client to communicate with only a first one of the two servers and to prevent direct contact between the client and the other of the two servers.
FIG. 1C is a block diagram of a networked computer system in which the foregoing general problem may arise. Client 102 is a computer device such as a workstation, server, router, or switch. Client 102 is coupled to network 104, which is an interconnected combination of computers, terminals, or peripherals used to provide communications between two or more points. A first server 106 and a second server 108 are coupled to network 104, logically separated from client 102. In one embodiment, client 102, network 104, and servers 106, 108 communicate using TCP/IP network protocols, and using HTTP protocol messages that comprise requests and responses. Such protocols are exemplary and not required.
Client 102 may communicate an HTTP request for a service to network 104. The request includes a name or other identifier of server 106, which client 102 expects to provide the requested service. Network 104 locates server 106 and routes the request to server 106, thereby establishing a logical connection 110 from client 102 to the server. Server 106 determines that it cannot provide the function or service solicited in the request, but that server 108 can provide the function or service. Accordingly, software elements in server 106 automatically divert or “redirect” the request to server 108 over a logical connection 112, which may physically travel through the network 104. Server 108 processes the request, generates a response message, and sends the response message back to client 102 over logical connection 114, which may pass through network 104.
In this scenario, when the client and the servers use HTTP, the response message may include a document formatted using a structured markup language, such as HTML. The HTML document may contain hyperlinks or other references to resources within server 108, or other servers or network elements. As a result, client 102 may select one of the hyperlinks or references, and thereby attempt to request a service of server 108 directly along connection 114. Server 106 would not be involved in processing such a request.
This result is undesirable in several circumstances. The server 106 may have been designated as authoritative for certain kinds of transactions. The server 106 may have redirected the original request to server 108 solely because server 106 cannot directly process the request, whereas server 108 can, but server 106 may need to remain in control of the overall transaction. For example, server 106 may have redirected the original request to server 108 just to carry out a specialized or subordinate task, although server 106 remains responsible for the total transaction or for presenting a consistent interface to the client 102.
Accordingly, there is a need in this field for a mechanism that allows a client request to be redirected from a first server to a second server, while keeping the first server in control of subsequent requests by the client for services of the second server.
In particular, there is a need for a mechanism that prevents the client from directly communicating with the second server even after the first server has redirected a request of the client to the second server.
There is a specific need in Internet protocol networks, such as Intranets or the Internet in which clients and servers use TCP/IP and HTTP, to force subsequent requests resulting from HTML generated by the second server to come back to the first server for further redirection.